Addressing Background
Addressing Primer
The concept of a device's end point name and its physical Internet address are intimately intertwined with negotiated security. Current HTTPS security semantics rely on the fact that a public key is bound to the device's resolvable name. The name is indexed into DNS to provide the device's physical network address. The TLS negotiation provides the client the necessary guarantees that the server is in possession of the private key, which corresponds to the public key tied to the name, in the presented certificate.
Let us define the following terms to help understand the solution space:
- Browser: the browser is an application used by a user to browse web content.
- Target device: the target device is the IoT device that the user is attempting to connect to (or configure) using the browser.
- Name: the name (or device name) from the browser's perspective, is the string typed into the browser address bar, which corresponds to the target device.
- Name resolution: the name resolution process is the method used by the browser to turn the name into an address.
- Address: is the physical (IP) based address that can be used for routing packets to the target device.
Building on these basic concepts, the following higher-level concepts are also important:
Unique Names and Address Binding
It is possible to give each device a unique name. For example, the hash of self generated public key of a device, can be used as a name with relatively strong guarantees of uniqueness. For this name to be useful, however it must be resolvable! For this name to be resolvable over the Internet, the unique device name will have to be combined with the address of a parent domain, to create a compound name.
Where DNS is being used as the name resolution process, we can construct the compound name in a device binding event.
There are a number of potential providers of parent (bound) domains:
- A private person could acquire a personal domain.
- The Internet service provider could dedicate a subdomain to the user.
- A device vendor could create a subdomain for its devices.
- An authority can setup a domain name dedicated for devices.
Private persons may not have the interest or technical capabilities to operate a domain. Personal ownership of a domain could be made more attractive by integrating domain and certificate management into a home gateway or, perhaps, a network storage device.
The network provider could host the naming service for devices. Network providers typically have the DNS infrastructure and the expertise already to be able to deploy this at scale.
A device vendor could operate a subdomain for their devices. Even if a manufacturer intends operating the subdomain for the full life of a device, there is the possibility of the manufacturer going out of business.
An authority (similar to how ISRG governs Let's Encrypt) could operate a subdomain dedicated to IOT devices. Since it is in the public interest, this would deserve to be government funded by participating nations or unions. Clearly, the definition of the binding process has a profound impact on the commercial ecosystem to be developed. It is therefore important that the solution proposed does not lock us into one operating economic model
Where a traditional certificate is used, this process is essential; the derived compound name becomes the common name of the device to which the certificate must be issued. Hence, the name must be constructed before the certificate can be issued. If the certificate is to be included in the device at the factory, then the name must be assigned at manufacturing time. If the name will not be assigned until later, then the certificate must be issued later.
Binding the device and provisioning it with a globally resolvable DNS name is a real world (economic) event, which also impacts the construction of certificates (if that is the method being used)
IP Addressing and Network
Concerning the device address: Local network addresses have identifiers that are distinguishable from public Internet addresses. These IP addresses will only have meaning on the local network. They can only be reached if traffic towards global addresses forward the traffic to the local network (Destination NAT). These addresses are reserved as link local, private use or are shared and are not globally unique. They are listed as Special-Purpose IP Address Registries https://datatracker.ietf.org/doc/html/rfc6890
| Purpose | IP Range |
| --------------------- | -------------- |
| Private-use | 10.0.0.0/8 |
| | 172.16.0.0/12 |
| | 192.168.0.0/16 |
| Link-Local IPv4 | 169.254.0.0/16 |
| Shared Address Space | 100.64.0.0/10 |
| Unique Local (ULA) | fc00::/7 |
| Link-Local IPv6 | fe80::/10 |
Browsers can distinguish between publicly routed Internet addresses and private-use or link local addresses. When a browser negotiates a TLS session with a server, the browser can detect that the server is reachable through such special purpose local IP addresses. The certificate warning displayed to the user can be different in this instance because the context is local and not on the global Internet.
Firefox has a method hostnameIsLocalIPAddress to check if an IP address is local or not [nsIIOService.idl - mozsearch]
https://searchfox.org/mozilla-central/source/netwerk/base/nsIIOService.idl#201
The resolved IP address of the target device is a critical part of current security decision making in browsers.
DNS domain name resolution
In a local network there is often no registered and resolvable DNS domain name, especially for devices that are not supposed to be directly connected to the Internet.
The local device addressing method is important for two reasons. Firstly, traditional HTTPS certificates are essentially cryptographic bindings between a common name (and address) and a public key. Secondly, the discoverability and usability of the local address will directly impact the user experience.
TLS certificates are valid for the identifier presented in the common name or subject alternative name. The most common identifier is a DNS name, but public IP addresses are also allowed. Under current CA/Browser Forum guidance, public CAs are not allowed to sign certificates if these identifiers use internal names. The domain name must be registered and resolvable. https://cabforum.org/wp-content/uploads/Guidance-Deprecated-Internal-Names.pdf
The naming mechanism is important also because the current browser standard is DNS resolution. The interaction of DNS resolution, proof of DNS ownership and certificate issuance are all intimately intertwined.
Solutions therefore will fall into two broad categories:
- Methods restricted to current standard DNS address resolution semantics.
- Methods that introduce new addressing mechanisms. These solutions offer more room for innovation, but necessarily will require deeper changes to guidelines and to the browser.
The DNS name resolution process is an integral part of current TLS session negotiation. A new security model for browser/IoT interaction either needs to fit into the current DNS model or replace the name resolution with another mechanism.
Multicast DNS
On the internal network (private IP address space) a different name resolution mechanism can be used.
Common practice is to address devices by a private IP address, which some devices advertise through Multicast DNS. This makes the devices discoverable, but it does not make them uniquely identifiable (for instance, every home network can have its own "printer.local" but these are actually distinct printers).
Multicast allows a device to advertise itself on the network and to be reached with a common name.
mDNS uses the domain suffix .local (IETF RFC6762) and can use RFC1918 IPv4 addresses (192.168.0.0/16), IPv4 link-local addresses (169.254.0.0/16), IPv6 link-local addresses (fe80::/64), and IPv6 ULA.
These addresses are often on the same physical Ethernet link, but more complex arrangements are possible. It is possible for a browser to identity the local context. For local connections, a different error message can be displayed. https://datatracker.ietf.org/doc/html/rfc6762
Multicast DNS can be used as an alternative local name resolution method. However some networks disable it so it cannot be assumed to always be there.
Link Address
Most devices already have a unique identifier like a MAC address for Ethernet, Wi-Fi or Bluetooth. The MAC address is a link level address in a network. However, there is an increasing push to randomize MAC addresses, see https://datatracker.ietf.org/wg/madinas/documents/
Currently the MAC address is not typically used in the negotiation of security between client and server.
However, there is a clear opportunity to introduce such concepts.
The Organizational Unique Identifier which is part of the full address, conveys meaningful information about the original manufacturer.
There are use cases where this information can be useful in establishing security credentials.
MAC addresses however can be modified and spoofed in most circumstances.
It's possible for the browser to identify that a resource is on the same physical link, however many devices are not on the same physical link and will be connected through routers, access points or switches. There are no standard POSIX APIs that can turn an IP address (or TCP socket) into a MAC address. The link local address in IPv6 may be derived from the MAC address.
X.509 certificates used in TLS require a verifiable public IP address or a public DNS name. Other X.509 based schemes exist that certify other layers in the network stack.
The link level address of the target device and/or security artefacts (e.g. certificates) attached to the link level address could be used as part of the security decision making process
Network Segmentation
Network segregation is generally good security practice. At a crude level the distinction between private use address(192.168.0.0/16) and global IP addresses is a form of segmentation.
A dedicated IoT network using a private VLAN could create a separate communication channel for device management isolated from other network traffic. A browser and gateway would have a method to identify IoT devices and "perform differently". A private VLAN dedicated to IoT could for instance be set to VLAN ID 2107. https://datatracker.ietf.org/doc/html/rfc5517
However, currently browsers are not considering the VLAN network they are operating in and it would require a significant standardisation effort to change the current networking practices to protect IoT network traffic.
Internal network subnets could be used to segment or separate clusters of devices. These clusters of physical addresses could be used as part of the browsers security decision making process.